Software system management tools define software elements, their interdependencies, and the rules that are required to construct a software product. These tools are necessary in view of the fact that a large software system typically includes a large number of individual source code programs that are compiled and then linked into a single executable program. This results in a number of software system management requirements. For example, a source code program may have a number of versions. Therefore, it is necessary to identify the proper version to be used in constructing the executable program. In addition, each source code program may require a distinct compiler. Thus, a mechanism must be developed to coordinate a source code program with the appropriate compiler. Software system management tools are also used to track program bugs. The most commonly used system modeler is MAKE.RTM., which runs on the UNIX.RTM.operating system.
FIG. 1 illustrates a prior art software system management apparatus 20. The apparatus 20 includes a central processing unit 22 which communicates with a memory module 24 and a hardware user interface 26 through a bus 28. A user working at the hardware user interface 26 inputs a rule-based description of a software system, which is downloaded into memory module 24. The rule-based software configuration description 30 is an integrated description of software elements, their interdependencies, and the rules that are used to construct a final product.
The memory module 24 stores a number of executable programs including a software user interface 32 (such as a graphical user interface) and a rule execution engine 34, which produces system construction commands 36. The executable programs stored in the memory module 24 also include a tool controller 38, compilers 40, and linkers 42. The tool controller 38 receives the system construction commands 36 and existing program files 44. The tool controller 38 operates in conjunction with the compilers 40 and linkers 42 to execute the system construction commands 36 on the existing program files 44 to yield an updated executable program 46.
The processing associated with prior art software system management devices is more fully appreciated with reference to FIG. 2. The input data to the apparatus is a rule-based software configuration description 30, such as provided by MAKE.RTM.. The software user interface 32 receives this information and passes it to a rule execution engine 34, which produces a set of system construction commands 36. For instance, if the rule-based software configuration description 30 specifies that files A, B, and C are to be combined to form file D, then the system construction commands 36 would constitute a set of commands that could be executed by the tool controller 38 to compile and link existing files A, B, and C to form file D.
Thus, the tool controller 38 executes the system construction commands 36 by interacting with the compilers 40, linkers 42, and existing program files 44. After the tool controller 38 has executed the system construction commands 36, an updated executable program 46 is produced.
Some software system management tools, such as CAPITL (Computer Aided Programming In The Large; developed at the University of Wisconsin), rely upon first-order logic. First-order logic refers to first-order predicate calculus wherein facts may be expressed as a combination of a functor and an argument. For example, in the statement "dog(fido)", the term "dog" is a functor, while "fido" is an argument. Thus, a functor may be thought of as a general truth, while an argument is an instance of the general truth. In first-order predicate calculus, functors are constant, that is, a functor's value cannot change.
First-order logic is used to express relations between elements. For example, the statement "conn(X,Z) :- conn(X,Y) & conn(y,z)" indicates that there is a connection between X and Z if there is a connection between X and Y and between Y and Z. Thus, it can be appreciated that first-order logic may be used in software system management to express relations between different files. For example, first-order logic may be used to express a fact that one file must be compiled before a second file is compiled.
Some system modellers, such as MAKE.RTM., do not use first-order logic, they use ad hoc rules. Ad hoc rules are less powerful than first-order logic. For example, using cad hoc rules, a transformation from A into B into C must be explicitly defined as a two step transformation A.fwdarw.B & .fwdarw.B.fwdarw.C. Ad hoc rules expressed in procedural statements of this type cannot automatically deduce the rules necessary to transform A into C. Therefore, existing software system management tools, such as MAKE.RTM., require a programmer to produce a set of ad hoc rules that are used to explicitly define software elements, their interdependencies, and the rules required to construct an executable file.
It would be highly desirable to provide a software system management tool that automatically assesses file dependencies and executes file handling rules. Such a system would allow a user to merely specify a desired property for a file to be formed. Thereafter, the software system management tool would execute all of the logic to achieve the desired result. Specifically, the software system management tool would generate and run the necessary commands to produce the desired file.
Automatic assessment of file dependencies and execution of file handling rules can, in theory, be realized using second-order logic. As indicated above, in first-order logic, functors are constant. In second-order logic, functors can be variable. That is, a functor variable can represent any one of a number of functor constants. Thus, in the statement "A(X,Y)". The functor variable "A" is not limited to being a "dog", as in the first-order logic example above, it can also be a "cat", "horse", etc. Second-order logic can be defined as generalized logic, based upon first-order logic, that allows logical deductions to be made from arbitrary facts, relations, or rules. Thus, in the context of software system management, a second-order system would provide a mechanism for making logical deductions from arbitrary files, file relations, and file handling rules.
Second-order logic has not been applied to software system management in the past because it is computationally expensive. Since a variable functor could be any of an infinite number of arbitrary relations, the resultant search space is prohibitive. Limited second-order logic can be applied to software system management if the functors are confined (bounded) to a set of user-defined predicates. However, this can still be an inherently limited approach. Moreover, without explicit separation of the import and export predicates, errors (e.g., in a second-order logic system description) can only be identified at execution time, not at compile time.
Thus, it would be highly desirable to provide a software modelling system that utilizes unbounded second-order logic, but does not have the execution penalties typically associated with unbounded second-order logic. Such a system would automatically define relations between files and generate commands to achieve a final product. Therefore, the user would not be forced to define all the relations between the files and the rules required to achieve a final product.
It would also be desirable to provide a software modelling system that can identify system errors at compile time. In particular, it would be desirable to provide a compile-time scope analysis. As understood in the art, scope is a rigorous framework of program code that limits the global visibility of program parts. Scoped information is only externally visible if it is explicitly exported by a defining module, and explicitly imported by the using module. Scoped information can only be imported into a module if it is exported by another module that it can see.
The following is a glossary of terms that will be used in the Detailed Description of the Invention.
Atom: An indivisible word or number, such as "dog" or "3". Words must begin with lower case letters.
Variable: An alphanumeric string that begins with an uppercase letter and can assume various values.
Term: A syntactic unit, either a simple atom, or a compound term, such as "dog(fido, brown)".
List: A set of terms enclosed within square brackets, e.g."[a, b, c]".
Functor: The head part of a compound term. For example, the functor of"dog(fido)" is "dog". In second-order logic, functors can be variables, for example "V(X, dog)". Functors define a general truth.
Arguments: The terms inside the parenthesis of a compound term, for example the arguments of"a(p(q),C)" are "p(q)" and "C". Arguments are parameters associated with a functor.
Ground: A ground term contains no variables. A ground functor is an atom, not a variable.
Rule: A logical statement of the form "X is true if Y and Z are true". It is written "X.rarw.Y & Z". The first part, X, is called the head. The remainder, Y & Z, is known as the body. Each term in the body is known as a subgoal.